The Be Newsletter
Issue 16, March 27, 1996
Table of Contents
BE ENGINEERING INSIGHTS:
A Recipe for Smooth Animation
By Robert Polic
There are two ways to do animation on the BeBox: Animate directly to the
screen or animate to an off-screen bitmap and render the results to the
screen.
The "direct-to-screen" approach may seem easier at first, and
may even be acceptable for rastered images, but for vectored images or images
made up of multiple rastered images, it usually results in flickery animation.
The "off-screen" approach is easy to implement and results in
very smooth animation, since the user only sees new frames when they're
completed -- not the steps required to draw each new frame. Of course there's
no free lunch: The off-screen approach does involve writing about 10 more
lines of code and there's a memory requirement for each off-screen bitmap.
The purpose of this article is to show how easy it is to use the off-screen
approach, using example code for creating a slider that's made up of two
parts: A background and a knob. The example draws the background from scratch
each time, since it's a simple object. The knob is a canned graphic that
we've created elsewhere (see Steve Horowitz's excellent article in last
week's newsletter, "Be Engineering Insights: craw, shex, and script:
Excuse Me?").
(Of course we could draw the slider directly to the screen, but every time
the knob moved, the user would see the background redraw over the knob and
then see the knob drawn onto the new background -- not very pretty.)
The first step is to create the on-screen view that we'll render into in
the window that we've already created:
BRect r.Set(SLIDER_L,
SLIDER_T,
SLIDER_L + SLIDER_WIDTH,
SLIDER_T + SLIDER_HEIGHT);
TSliderView slider_view = new TSliderView(r, "slider");
AddChild(slider_view);
Since we're using a canned graphic for the knob, we might as well
create a bitmap for it in the constructor for TSliderView:
BRect r.Set(0, 0, KNOB_WIDTH, KNOB_HEIGHT);
unsigned char* knob = new BBitmap(r, B_COLOR_8_BIT);
knob->SetBits(slider_bits,
knob->BitsLength(),
0,
B_COLOR_8_BIT);
(If the original graphic is a 24-bit bitmap, replace B_COLOR_8_BIT
with B_RGB_32_BIT.)
The next step is to create the off-screen bitmap that has the same dimensions
as our on-screen view, and an off-screen view that we'll draw into:
r = Bounds();
unsigned char* offscreen = new BBitmap(r,
B_COLOR_8_BIT,
TRUE);
BView offview = new Bview(r,
"off",
B_FOLLOW_ALL,
B_WILL_DRAW);
offscreen->AddChild(offview);
Note: When you're creating a bitmap that you intend to attach a view to,
the left and top values for the bounds must be 0.0.
That's it for creating an off-screen drawing environment. Now we need to
draw into it. First we lock the view's parent to prevent anyone else from
accessing it:
offscreen->Lock();
Next, start drawing:
r = offview->Bounds(); // get view's bounds
offview->SetHighColor(R, G, B); // set view's high color
// same as on screen
offview->FillRect(r); // fill bitmap with color
// draw the slider background...
offview->SetHighColor(0, 0, 0); // set pen to black
offview->StrokeLine(BPoint(x, y), BPoint(x1, y1));
.
.
.
// copy the knob
r.Set(knob_x,
knob_y,
knob_x + KNOB_WIDTH,
knob_y + KNOB_HEIGHT);
offview->DrawBitmap(knob, knob->Bounds(), r);
The last step is to render the result to the screen and unlock the view's
parent:
offview->Sync(); // make sure rendering is done
DrawBitmap(offscreen, BPoint(0, 0));
offscreen->Unlock();
That's all there is to it. Of course, don't forget to delete the
bitmaps that were created in the SliderView's destructor. Look for the full
source example of this slider on our FTP site: ftp.be.com/pub/Samples/Slider.tar.Z
(the file is also available in .zip and .sea.hqx formats).
BE DEVELOPER PROFILE: Stairways Software Pty. Ltd.
Last week, Peter N. Lewis of Stairways Software Pty. Ltd. voyaged all the
way to the U.S. from Perth, Australia, just to visit us at Be. Well, OK,
so he also came to spend some time with our friends at Metrowerks in Texas,
but we're pretty sure hitting up Jean-Louis for another BeBox was his real
mission.
Peter N. Lewis may be a familiar name to many of you. A well-respected,
long-time Macintosh developer, he's a thriving shareware and freeware developer
with a long list of Internet applications to his credit. Among them: Anarchie,
an FTP and Archie client, which you can use to browse FTP sites and upload
and download files, and NetPresenz (previously called FTPd), which you can
use to turn your system into an FTP, WWW, or Gopher server.
As a communications developer running up against the proverbial performance
walls of traditional PC architectures, Lewis believes "The BeBox has
a lot of potential for the future. It's a simple, clean system -- something
lots of developers would like to get back to. With its multiprocessor design,
it's also Internet-capable and fast!"
The modern Be OS(TM) is also a big draw with its preemptive multitasking
and memory protection. "I write mostly Macintosh communication programs,
and not having preemptive multitasking is a real problem." In addition,
one of the most attractive aspects from a technology adoption viewpoint
is that "the framework is built right into the box, so you don't have
to wait for the framework to catch up in order to take advantage of new
capabilities."
As a shareware developer, Lewis admits that the BeBox isn't a financially
viable platform for him yet. Typically, he finds that only 2 to 20 percent
of shareware users take the time to send in shareware fees (he thinks "about
the price of a paperback book" -- or $10 -- is reasonable). This means
a platform needs a large installed base before a shareware developer like
him begins to see black on the bottom line. Even so, he believes in the
BeBox's potential so much that he's already written a web server for it.
And he's feeling "a little guilty" that he can't be doing more
for the BeBox right now, as he embarks on a few-months break from his work
in Australia.
"I hope the BeBox picks up enough users so that I can start to develop
seriously for it. It's certainly a lot easier to program for than the Macintosh,
despite using C++," he says. "And if we get some good languages
on the BeBox, then it will be even more pleasant. I wonder how hard it would
be to build a Java interpreter straight into the OS?"
Why would he recommend other developers consider the BeBox? "Because
it gives you an opportunity to get in on the ground floor. Because it's
much easier than developing for other machines. Because there's no competition.
And because it's fun!"
"As a Macintosh developer, I've heard all the reasons why I should
develop for the PC, but I'm still writing for the Macintosh."
And now, the BeBox.
For more information on Stairways Software Pty. Ltd.'s Internet solutions,
visit their web site at: http://www.share.com/share/peterlewis/.
Forward Motion
By Jean-Louis Gassée
"All right," they say, "your OS offers some advantages, we'll
concede that. But just you wait, the moment The Big Guys wake up and realize
you have some interesting advantage, they'll unleash their immense technical
and marketing resources. In no time, they'll catch up with you, meet or
beat all your differentiating features. Add their marketing might and you'll
be reduced to a footnote." Thank you, may we go quietly now?
Fortunately for all of us having one kind of stake or another in Be's future,
it's not quite like that. On the contrary, even if it appears a little counterintuitive,
we're more likely to increase our technical lead than to see our noble and
worthy elders catch up with us. This, of course, makes all sorts of assumptions
about us staying focused, vigilant, hungry, and mindful of our station in
life. We have a lot to prove. With this cautious frame of mind, let's turn
to life inside the sausage factories, to building system software. Call
it entropy, call it politics, but any piece of software inevitably reflects
the age, the mores, the size of the organization that built it. Your coefficients
may vary, but the formula stays the same. And it will apply to us, eventually.
For The Big Guys, large incremental projects need more and more time between
major releases.
Even the best-run company in the business, Microsoft, needed about five
years between Windows 3.0 and Windows 4.0 (as your hard disk knows it --
Windows 95 for us humans). Apple will need a similar amount of time to move
from System 7 to System 8 (a/k/a Copland). For the previous iteration, the
time interval was 2 to 3 years. The same phenomenon applied to major releases
of mini and mainframe operating system software. After an exuberant youth,
software settles down and the interval between major releases increases.
Put another way, the more mature PC operating systems are entering a phase
of diminishing returns, while we're still on the early, ascending part of
the curve.
Invoking "Skunk Works" might sound both pretentious and overused.
Still, Ben Rich's and Leo Janos' book (now in paperback at $14.95, unfortunately
defaced by a Tom Clancey quote...) is a wonderful read -- a rich source
of inspiration and analogies. They offer good models when contemplating
what a small, focused organization of engineering demigods can accomplish:
The U-2, the SR-71, the Stealth fighter no less. They also offer sad models,
such as when the immune system built by the founding father, Kelly Johnson,
and carefully maintained by his successor, Ben Rich, was finally overwhelmed
by the corporate and Pentagon lymphocytes. Warehouses filled with government
paperwork for a single project.
Lesser mortals such as ourselves can still enjoy the advantages of a small
organization, happily focused on a product in the early part of its life
cycle -- at a time when we can make bigger and faster strides than our elders.
Our developer software release 1.1d7, shipping next month, will be a test
of this statement.
Still, what about Windows catching up with the Macintosh? Doesn't this destroy
our thesis? Au contraire, Microsoft was the smaller company in those days,
while Apple was the big rich target. Admittedly, Microsoft enjoyed an unfair
advantage: Stable management, the same leader for 20 years. This continuity
is reflected in the product strategy: Continuous improvements from QDOS
to Windows 95. Apple, on the other hand, had discontinuous leadership. This
wasn't always bad. Jumping from the Apple II to the Macintosh, while unpopular
with some, started what has become a $12 billion company. But today, Apple
is in the uncomfortable position of playing the continuity game against
the best player in the field.
Meanwhile, having sinned and learned in another life, we're committed to
making the best of our discontinuity, of our lack of organizational and
architectural past and baggage.
Be,
the Be logo, BeBox, and GeekPort are trademarks of Be, Inc.
Copyright © 1996 Be, Inc.
Send any questions or problems regarding this service to webmaster@be.com.